游戏版本管理：小游戏开发者需要了解的服务器模块之三
Editor's Note
The following article is from 可以叫我才哥 Author 道才
本篇是 小游戏开发者需要了解的服务器模块 系列第三篇，作者道才（才哥）。下面的列表中，红色部分为本篇内容：
登录 首次进入的静默登录处理 静默登录与绑定账号
从服务器获取配置 维护公告 配置和开关 白名单机制 运营邮件
游戏版本管理（by 才哥）
版本与更新机制
今天我们聊一聊游戏运营里的版本运营模块的工作，介绍一下这个岗位的主要工作内容。
简单来说，版本运营日常工作主要是负责保障游戏线上运营的稳定性，同时也可能需要去处理一些线上的突发事件。
基于此，做好版本运营我们可以从以下几个方面进行展开，更好的服务于项目以及我们的用户。
目录：
1. 基础
1.1. SDK接入
1.2. 运营工具
1.3. GM工具
1.4. 平台能力项接入
1.5. 版本维护更新发布流程
1.6. 渠道上下架操作
1.7. 数据埋点
1.8. 运营数据后台
2. 进阶
2.1. 口碑运营
2.2. 版本规划
2.3. 测试服
2.4. 版本主题
2.5. 运营需求池
2.6. 其他
1. 基础
对于版本运营同学来说，可以从游戏研发期开始介入，完成一些基础性的版本运营工作，比如SDK接入、运营工具、GM工具以及平台能力项接入等等；在进行游戏测试调优之前，还需要梳理版本维护更新发布流程、多版本（包）管理、渠道上下架操作、tlog埋点以及运营数据后台等等。
1.1. SDK接入
关于SDK的科普可以参考我之前写的《关于移动游戏SDK，你想了解的都在这里》。今天我们不聊那么细，简单介绍SDK所包含一些基础内容和拓展内容。
1.1.1. 基础内容
账号体系、充值以及SDK数据上报（一般是客户端日志数据）
账号体系
从用户角度来看，登录游戏的方式可以有多种，比如账号密码登录、手机号登录又或者第三方账号如QQ、微信、微博、苹果id登录等等； 而对于同一个游戏（不同渠道包算不同的）来说，这些登录方式最终都是一个账号体系之下的； 从产品角度，其实支持多种登录方式，那么这些不同的登录方式其实就需要去对应的开发者后台申请对应的参数。
关于这些参数的申请，不同的公司的流程可能不一样，有的可能是中台部门负责或者商务同学负责，也有的可能是版本运营同学负责。但是不管怎么样，最终基本都需要版本运营去进行对接协调（作为项目组与其他部门之间的沟通桥梁），所以作为版本运营，把这些流程与实操都熟悉掌握很有必要。
tips：一般参数申请需要提供产品的基础信息，比如 名称、包名、icon以及简介等等，这部分差不多就是需要版本运营同学来准备了。
充值
对于有内购的游戏来说，充值是必不可少的。国内常见的充值有支付宝、微信支付与苹果支付等，此外还有手机话费卡支付、银联卡支付等等；海外可能就是GiftCard、PayPal、VISA/万事达等等。同样的，这些支付方式也是需要去对应的开发者后台申请参数，它们的流程和账号体系基本一致。
SDK数据上报
SDK数据上报一般是SDK自带的一类，主要是设备信息与SDK相关信息一类的数据，可以提前和中台部门了解下具体有哪些预设数据上报等等，这样就便于后续测试验收。
1.1.2. 拓展内容
除了上述的基础内容之外，我们还可能涉及到其他的一些拓展内容，比如：
为了方便用户在游戏里进行交流，需要接一些第三方的语音SDK；
为了更好的采集用户行为数据，可能会接入做的比较好的第三方数据平台的SDK；
为了进行流量变现，可能会接入第三方的广告SDK；
为了方面用户手机号登录，可能会接入手机号一键登录的SDK；
为了收集用户体验游戏时设备的一些奔溃信息，可能会接入第三方的崩溃上报SDK等等。
同样的，我们如果需要上架一些联运渠道，则还需要接入这些联运渠道的SDK，这个SDK则会带有上述第1部分中的基础内容以及一些渠道定制化的内容（比如浮窗功能、内置社区等等）。
以上只是部分拓展内容，实际项目中会根据项目本身的产品需求进行第三方SDK的选取，而对于第三方SDK的接入也基本上都是 提供产品的基础信息用于参数申请，作为版本运营的同学也一定需要搞清楚这个SDK的功能是什么，以及如何验收。
1.2. 运营工具
顾名思义，运营工具就是在游戏运营过程中会使用到的工具，常见的发公告、跑马灯、全服邮件等等就是。
我们按照功能类型可以分为以下几类，具体详情需要根据具体项目进行定制化：
用户信息查询
通过用户账号、角色ID或昵称等查询用户信息，不同的产品信息展示有所不同
当前详情信息（如等级、充值金额、背包信息等等） 历史信息记录（如道具操作流水、充值流水等等）
资源管理
比如公告、跑马灯、全服&单人邮件、push消息等等
服务器状态管理
开/关服、预开服（维护）、排队人数设置、白名单等等
游戏功能管理
为了尽可能保证游戏线上运营的稳定性以及能尽快的响应线上突发事件，游戏功能管理模块可以无限拓展。最简单的就是对可能出现问题就会影响线上的功能都做开关功能，在线上出现问题时第一时间进行功能关闭处理，让负面影响尽可能小。
比如 角色 开关，关闭某个角色则该角色无法使用，如果该角色出现数值异常则可以第一时间先关闭之； 比如 充值 开关，关闭某充值则该充值项无法充值，如果该充值出现异常比如充值给的奖励配错了，则第一时间关闭之； 比如 某活动出现问题，我们也可以关闭活动，则也可以减少损失； 再比如 某期间 要求玩家不能改名，我们就可以关闭改名功能等等。
以上只是部分由于某功能异常导致的问题的快速响应，作为版本运营同学需要对游戏的各个功能都有清晰的认知，又能考虑到可能出现问题的边界情况及其负面影响，然后和对应的策划一起商量确定其功能开关的具体功能为最佳。
通过上述功能可以看到，运营工具就是游戏运营同学操纵游戏的核武器，熟练掌握并能不断完善该核武器，可以极大提高我们的工作效率以及应对突发事件的处理能力。
（提个小问题，某运营同学在给个人发送补偿邮件的时候不小心发到成了全服，怎么快速处理可以让损失最小？）
1.3. GM工具
GM工具其实也是运营工具的一种，这里我狭义的指代对用户状态操作的工具
通过用户账号、角色ID等对用户进行相关的状态操作，不同的产品用户状态有所不同
处罚类型（如：封号、禁言、禁止某玩法、禁止排行榜等等） 信息修改（如：强制改名、道具删减、修改段位等等）
比如，某用户在体验游戏的时候开挂了、故意送分了等等，我们就可以对其进行封号处理；某用户昵称不雅被举报了，我们就可以对其进行强制改名等等。
需要注意的是，不管是运营工具还是GM工具，我们在设计的时候都需要考虑该功能使用后如果会影响玩家的正常体验，则一定要给予玩家合适的前端提示。比如封号后，玩家登录的时候需要有弹窗提示告知玩家 因为什么原因被封到什么时候之类的；我们关闭某个功能后，需要在玩家点击该功能的时候提示 该功能暂时关闭之类的。（具体功能具体分析了）
此外，就是这些工具的具体功能需求，对于运营同学来说就是在某个网页前端进行输入与结果的展示。而实际上涉及运营与网页前端的交互、中台（制作网页前端的部门）与游戏服务器之间的交互、游戏服务器与客户端之间的交互以及玩家与客户端之间的交互。其中前2类交互需要版本运营同学去撰写具体的需求，后2类的交互则需要版本运营与策划沟通并大多数情况下由策划去撰写具体的需求。
1.4. 平台能力项接入
像我们在SDK接入里提到的很多功能如QQ、微信和微博等第三方账号登录方式，一般来说它们也提供诸如分享等功能，这些就属于平台能力项。不过，这些第三方的能力项大部分都是仅用于各自独代的一些产品。
此外，我们接入的联运渠道，它们一般也会有一些平台能力项供接入使用，比如浮窗、内置社区等等。
我们可以根据自己的产品需求来进行相关能力项的选取。
1.5. 版本维护更新发布流程
当我们的产品开始接触用户，就会有新内容、旧内容迭代以及一些问题修复等等，这就涉及到维护更新与发布了。有明确的更新发布流程，可以让我们这类工作高效有序的展开。
一般来说，更新可以分为以下2类：
强更
也叫冷更、大版本更新等等，用户需要更新一个完整的包，大多数时候，这种更新需要停服操作
热更
这是一种更新频率非常高的方式，用户在现有的版本基础上更新一些游戏资源即可，一般不需要停服操作
对于强更这种情况，一般都是提前准备好了完整的包上架渠道或者CDN，到指定的时间进行停服操作，操作结束后玩家自动更新最新的包，这种情况一般涉及到比较大的版本内容更新或者比较底层的代码改动。
对于热更这种情况，一般可以分为两种：用户无感的更新与用户需要重启游戏的更新。无感的更新多数情况下是一些纯数据或少数美术资源层面的更新，玩家在游戏中就静默更新了。用户需要重启游戏的更新则可能涉及到相对较大资源或者是比较关键的数据（比如竞技类游戏里的 战斗数值）更新，玩家在游戏大厅则需要重启游戏进行更新。
其实，很多游戏都可以做到基本不需要停服更新，比如多个login、game服等，涉及到服务器需要重启更新的内容进行相关子节点的轮流重启就可以了。
以上的一些具体更新逻辑则需要版本运营同学和对应的前后端技术、运维和测试同学一起进行协商沟通并最终确定。
一般来说，更新流程可以概况为以下（具体项目具体讨论）：
确定版本更新内容 pc端验收（内网） 手机端 ftp环境验收 （内网） 手机端 cdn环境验收 （预发布，无限接近外网） 运营发布公告、跑马灯、各社群&自媒体平台发布更新公告（告知更新时间、类型、内容、补偿方案等） 发布前的操作（服务器状态操作，是否灰度等等） 线上发布
1.6. 渠道上下架操作
一般除了官方渠道（官网、官方社区等），我们还可能上架一些平台或者联运渠道等，这就涉及到多版本（包）的管理以及渠道的上下架操作。
作为版本运营，尽量熟悉不同渠道的上下架操作是有必要的（虽然很多时候这些操作可能是商务或者渠道对接同学负责）。
在本地版本包的管理上尽量的规范，这样在实际的工作中就可以更加方便。
常见的上架需要准备的材料有如下几类：
安装包 五图（icon如果换则加上） 更新内容 主副标题（如果换的话） 是否新增内购档位等
不同的渠道对这些素材的要求可能不同，整理一份材料需求清单，创建不同渠道的材料文件夹进行统一管理可以让工作效率大大提高。
关于渠道包提审，在实际操作中可能会遇到很多不同的问题，我们都需要根据实际情况进行一一处理。
常见的有以下一些场景：
某渠道SDK更新了，且是需要强制更新版本的，对于这种情况，建议在原定的上架时间前2-3周找商务同学进行各渠道SDK更新状态的统一汇总以尽可能避免此类情况； 某渠道新增了一些屏蔽字，是否第一时间补充到游戏屏蔽字库了； 联运渠道包不能出现一些外链引导类的功能以及广告sdk等等； 一些新的合规政策的出台，比如最近1年越来越严格的关于隐私政策&用户协议、防沉迷、隐私清单等的要求，我们需要去研究解读具体的政策条款，同时也要去了解渠道对这些政策条款的要求，然后合到游戏里。
以上其实就需要版本运营同学也要时常关注各渠道以及国家在游戏方面的一些政策规定等，然后进行针对性的预警或处理，以确保项目稳定有序开展。
关于iOS提审与发布可以参考我后续要出的一期介绍哈（敬请期待）
1.7. 数据埋点
数据埋点就是对用户游戏行为以及游戏本身数据的记录，常见的用户注册、创角、登录、登出等等，此外就是和玩家对游戏的各个玩法系统的行为数据事件的采集了。
这些埋点数据都是元数据，也就是每一次行为事件都会记录成一条，我们后续复杂的数据分析都是基于此。
一般来说，我们可以将事件的属性分为两类：通用属性与事件专属属性。
通用属性 可以理解为在每个事件里都需要记录的属性（取不到的不算），比如用户的账号、角色id、等级、vip等级、创角时间、昵称、渠道、平台等等。
事件专属属性 可以理解为每个单独的事件所需要记录的属性，其实这个是数据埋点设计的核心，它的设计思路其实需要反推，比如我需要通过玩家对局（moba）来分析英雄出场率、胜率以及一些对局属性数据来进行平衡性调整等等，则可以做如下埋点设计（简单的参考）：
| 字段名 | 字段说明 | 字段类型 | 备注 |
|---|---|---|---|
| battle_id | 对局id | 数值 | |
| role_id | 角色uid | 数值 | |
| rank_before | 对局前段位 | 数值 | |
| rank_after | 对局后段位 | 数值 | |
| game_type | 游戏模式 | 数值 | |
| elo_before | 对局前elo | 数值 | |
| elo_after | 对局后elo | 数值 | |
| elo_type | elo类型 | 数值 | |
| faction_id | 阵营 | 数值 | |
| hero_id | 英雄 | 数值 | |
| skin_id | 皮肤 | 数值 | |
| equip | 最终装备 | 列表 | |
| summoner | 召唤师技能 | 数值 | |
| runes | 铭文 | 列表 | |
| level | 等级 | 数值 | |
| kill | 击败数 | 数值 | |
| death | 死亡数 | 数值 | |
| assist | 助攻数 | 数值 | |
| economy_all | 总经济 | 数值 | |
| economy_creep | 野怪经济 | 数值 | |
| score | 评分 | 数值 | |
| kill_soldier | 补刀数 | 数值 | |
| participation | 参团率 | 数值 | |
| ... | ... | ... |
当然了，数据埋点这方面版本运营同学不一定需要去负责，像数据运营或者对应系统的策划又或者数值策划等都可以参与到这个工作中来。除了我们需要用于分析的属性之外，技术也可能会提一些用于定位问题的属性字段，加到埋点设计里即可。
1.8. 运营数据后台
有了埋点数据之后，我们就可以进行运营数据后台的搭建了。
当然了，现在很多公司都有自己的的数据中台，我们直接按照他们制定的数据埋点的统一格式来，那么基本上就可以很简单的接入到对应的数据后台了，常见的一些数据报表基本也就不需要额外去设计了。又或者我们接入一些第三方的数据后台，按照对应的数据埋点要求进行埋点设计，一样可以快速的完成一些基础的数据报表设计。
其实，有了元数据，数据分析就都好做了。
常规报表的制作，特殊的专项数据分析则可能涉及到SQL或者python的一些处理，这方面可以参考咱们公众号历史文章进行学习。
不过，现在除了游戏里的一些玩家行为数据之外，我们还有买量数据，这方面也是可以集成到运营数据后台的，当然也是可以单独拿出来做分析，结合游戏里的数据看用户质量（留存、LTV、roi之类的）。
2. 进阶
在基础部分，我们主要介绍的是属于基建部分，如果要把版本运营做的更好，我们需要更多的思考，对产品的以及对用户的。
2.1. 口碑运营
从游戏测试调优开始到游戏上线运营之后，我们都需要开始关注口碑运营这块的工作。核心就是日常线上环境的监控，及时妥善处理游戏的各类突发运营事件。
游戏面向用户后，就需要注意口碑。任何一个负面的问题都会导致口碑的下降，而每次妥善的处理也往往能将口碑拉升。
所以，我们需要游戏线上的运营情况，这个情况可以是直观的数据曲线，也可以是外网舆情，还可以是客服反馈等等。
从数据曲线的折线变化我们可以及时发现线上可能的问题，比如服务器宕机导致在线数陡降，接着我们就从外网舆情发现玩家反馈登录不上游戏，客服也反馈过来很多玩家掉线等等。
又或者数据曲线都正常，有玩家反馈某玩法无法参与等等。
这个时候，版本运营的同学就需要开始跟进并推动处理这一系列问题。
一般来说，大致流程可以是这样：
收集问题（尽可能详细，用户账号或角色id、时间、场景、具体问题等） 可自测的先自测（比如登录问题、充值问题、玩法参与等比较显而易见的） 同步线上问题群（相关模块负责人都在的专项群） 评估风险等级 高风险的紧急处理方案（这个时候要善于使用运营工具和GM工具等） 处理方案同步用户（公告、跑马灯、社群、自媒体，客服答复玩家的统一口径等） 协调推动问题的处理 复盘总结，一方面尝试从机制上避免，另一方面看是否可以完善处理机制等
作为版本运营，需要对游戏机制（一些功能的实现逻辑）有非常熟悉的理解，以便于能第一时间对问题进行判断，尽快响应！
在事故问题的处理中一定要积极主动的push，协调各部门尽快修复上线！
同时和其他模块运营同学（尤其是玩家运营、自媒体运营等）保持紧密配合，尽可能妥善处理外网舆情。
简单概况对突发事件的处理就是要做好：全方位（公告、跑马灯、社群自媒体等）告知玩家处理方案（时间、具体措施、补偿方案等），尽快处理，统一口径！
除了高风险的突发事件的紧急处理外，也需要去关注日常玩家对游戏的反馈，不管是bug还是设计体验反馈，都记录备案（日期、归属版本、反馈类型、反馈内容、反馈频度、玩家信息等），为后续版本优化提供参考。
一定注意，显而易见的bug和一些合理的建议，能尽快进版本就尽快，否则容易让玩家觉得我们不作为而影响口碑。
2.2. 版本规划
一般来说，游戏性的版本规划可能是很早就有制定，不过在运营阶段，收集到线上玩家的一些有效反馈建议以及从运营数据分析得到的一些参考建议等都可以作为后续版本的开发方向。
常见的bug类问题的修复，体验优化类的需求以及玩家的一些对玩法或资源追求的合理性需求等等。以上这些则需要运营同学对产品、对用户以及对数据都有比较深刻的理解。一定注意，并不是玩家的反馈建议就一定要听！
2.3. 测试服
现在很多上线运营的游戏都有测试体验服，比如每次大版本上线之前，由于涉及到的新增功能点较多。为了更完善的测试（相对趋近于线上正式环境），我们就可以先安排上线测试体验服，邀请一批玩家进行体验。一方面可以找bug，另外一方面还可以提前体验新内容然后专项反馈，让我们可以进行上线前的调优，这样正式上线后的版本的版本质量更有保障。
其实，对于测试服与正式服同时存在的情况，对于项目组来说相对而言是维护了两个正式版本（同时还有开发版本需要维护），多多少少会存在一些的工作压力。如何去协调测试服与正式服的工作就显得比较重要了！
这里，我们的做法大致是这样：
根据实际的产品需求，不定期进行测试服的测试招募（针对性招募指定属性人群），进行专项的测试。比如要上新的英雄或者玩法，招募一批玩家在指定时间按照测试要求参与，专项提交这些英雄或玩法的bug与体验反馈，负责该英雄或玩法的策划owner可以加入到测试群了解玩家反馈也可以等测试周期结束后统一看我们汇总的反馈，或者参与组织的专项访谈！如果测试中间遇到一些阻断性的bug，比如英雄无法使用、游戏高频闪退、英雄数值变态等，则需要及时处理并更新；如果遇到的是一些其他类型不影响核心测试目的的问题或反馈，则暂时先无视。
另外，就是如果与正式服运营版本之间存在人力需求交集，以正式服为主。
除了专项测试之外，特定的在正式服上线前2-3周进行一次相对正式版的测试服跑测，主要是版本稳定性测试。
此外，就是非官方组织的测试周期外，有余力的情况下可以多对测试版本进行一些维护，确保后续需要使用的时候合版本的时候问题尽可能的少！
测试服也是需要很好的维护，如果招募的玩家发现测试服问题一大堆且官方基本不维护，正式服上线后测试服就存在的很明显的问题还在，那么这些玩家参与测试服的积极性甚至对游戏的积极性都会大打折扣！
2.4. 版本主题
新的版本内容最终确定后，我们就可以考虑对这个版本进行主题包装了，具体主题我们可以找文案策划一起勾兑，然后找平面设计进行相关素材的制作。主题包装的作用有一定的品宣效果，配合买量或者渠道动作，可以把价值发挥到最大。
常见的主题包含涉及到的工作可以有：
新的icon 新的登录界面 新的大厅主KV 新的宣传图 新的CG或视频 官网、社群与自媒体的主KV
在新版本正式上线前1-2周，我们就可以安排陆续进行新版本爆料，营造氛围！
同样的，我们在定好更新内容后，可以将更新内容准备两套，一套详细的图文类用于官网和社群自媒体，一套简单的用于游戏内公告。
这个时候，我们还可以和商务一起，将新版本的亮点、卖点梳理，然后找渠道进行资源置换！
如何更好的进行版本主题包装，如何借此协调各方的资源，将新版本的buff加到最大是版本运营全局规划能力的一种体现！
2.5. 运营需求池
除了收集的玩家有效反馈建议和bug之外，我们在运营过程中也会有一些从运营出发的需求，比如渠道新功能希望我们能接入一下、市场或买量同学与外部渠道（短视频平台等）的合作需求、运营工具或GM工具新增需求等等。
这个时候，作为版本运营则需要对这些需求进行归档整理成运营需求池，考虑到项目组开发人力是有限的，所以并非全部的需求过来都要立马安排上，如何协调，就需要版本运营好好考虑了。
我个人比较喜欢的做法就是会先自己熟悉下这些需求的具体背景、大致可能需要的人力资源，然后再跟需求方一起沟通优先级，再组织会议沟通进行需求的评审（类似策划需求评审，需要项目侧PM、需求发起者以及相关人员一起）。
有些需求可能项目组内部就能消化，比如短视频平台的合作需要的只是礼包或者游戏内宣传图，这类找美术提需求游戏内添加配置即可；有些需求可能还需要中台部分协助，比如渠道新功能，我们需要找中台进行聚合，则还需要考虑中台的排期。
懂技术、会项目管理，是版本运营同学多多少少需要掌握的！
2.6. 其他
在线上运营的过程中，我们还会遇到很多各式各样的场景，版本运营需要根据不同的场景进行合理的安排处理，随机应变。
除了我们之前提到过的突发事件（bug类）的处理外，其实像外挂或者其他一些玩家违规游戏行为的处理也需要得到重视，营造和谐的游戏环境很重要。
关于外挂，需要考虑其影响面，如何针对性的处理：一方面需要出台相关处理流程（如何判定、判定后如何处罚、如何公示等等），另一方面则需要和项目组一起制定能从机制上避免或者自动处罚外挂的方案。
关于违规游戏行为（比如恶意送分、刷分、退款、言语辱骂等等），其实也和外挂处理的流程逻辑类型，一方面从运营角度处理，另一方面从机制上完善。
此外，还有一些诸如开服、合服、关服以及账号迁移等等都是版本运营在工作中可能涉及的内容，这些都根据具体问题具体处理就好了，不再展开！
以上就是本次的全部内容，很多模块并没有详细展开，如果你感兴趣，可以进入胡扯游戏群加作者好友一起交流学习，谢谢！
https://civitai.com/images/21033220
特别介绍
有很多重要内容，公众号发不了，但群里特别能聊。
群里有独立开发者，游戏公司创始人、大厂负责人、量子理论研究者……
关注公众号可以进群一起唠嗑，独立游戏、商业游戏、流量游戏、研发、投放、发行、运营、招人 都能聊，纯唠嗑也欢迎。
下面几个系列文章花了不少精力，可以读一读：
创业系列：
效率系列：
产品分析：
立项系列：
混变系列：
运营系列：
成长系列：
会议系列：
奇技淫巧：
荐号系列：
电子游戏是怎么赚钱的：
再多读几篇：
都刷到这里了，不来个「点赞」「分享」「在看」一键三连吗？